NAT traversal
https://squid-ink-cafe.com/lag/lag-ready-05/#nat-a
https://tailscale.com/blog/how-nat-traversal-works
NAT越えのための技術
UPnP
UDP hole punching
STUN
connection reversal
TRUN
WebRTC
UPnP
Universal Plug and Play
もともとは機器を接続するだけでネットワークに参加するための仕組み
IPアドレスの取得
別の機器の発見、制御
XMLとHTTPで情報をやりとり
UPnPでNAT機器のNATテーブルにエントリーを追加してNAT Traversalを実現
通信が必要な時だけポートを開け閉め、エントリー追加、削除をする
素人が自前で変なport fowardingするようより安心かもしれない。
ただWEBカメラ等の常時開放系とか、開けるポートがわかってしまう製品だと、ただ穴を開けるだけと同じなのでセキュリティホールになりがち
実際ハッカーのDDOS用のクライアントに使われたりしがち
UDP hole punching
Cone型NATで有効なNAT越え技術
Cone側のエントリーさえあればパケット送信元を無視して内部へ通信を許可するという仕様を利用
Cone型NATとは受けつけたUDPパケットの送信元を見ない仕様
UDPのみの策なのでTCPは非対応。
synmetric型のNATだと非対応
synmetric型だと送信先によって外部のポート番号が変わる、受け付けたUDPパケットの送信元も確認しているのでフォワーディングしてくれない
STUNはこの仕組みを使っている
前提としては通信の双方がNAT配下にいる場合
UDP hole punching用のサーバーにたいして双方LANからWANへUDPを送りつける
ここでNATテーブルにエントリーが乗る
サーバーは双方のUDPパケットを受け取っている状態
つまりCone 型NATの穴であり通信先となる相手のIP アドレスと、ポートを知っている。
UDP hole punching サーバーに通信相手のIPアドレスとポートを問い合わせて相手の情報を双方で得る
得た情報を利用して通信先となる相手にUDP通信。
事前にUDPで通信してNAT エントリーが乗っているのでCone型なら通信可能
実際にはrestricted port cone natだったりすると、過去に送信先となったかを確認している
そのため、さらに双方で実際の相手先に一度通信してNATエントリーを追加する必要がある
UDPの場合はNATエントリーのタイムアウト問題がある
キープアライブのために何もなくてもダミーでキープアライブ用パケットの送出が必要になる
STUN
Session Traversal Utilities for NAT
UDP hole puhcingを実現する標準仕様
udp hole punchingするだけならどんなメッセージプロトコルでもいいが、STUNが標準プロトコル。
仕組みとしてはUDP hole puchingサーバーが具体的にはSTUNサーバーとなる
NAT配下のプレイヤーの外部IP,外部portを互いに通知し合うためのサーバー
クライアントとSTUNサーバーのメッセージフォーマットやもろもろ決まっている
https://tex2e.github.io/rfc-translater/html/rfc5389.html
https://html5experts.jp/mganeko/20618/
https://qiita.com/Jxck/items/a59d8896b845a8da2445
code:text
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ゲーム、WEB RTCのP2P通信をNAT越えで確立するために主に利用される
connection reversal
TCPのestablished パケット(戻り)は当然NATを通ることを利用
前提としては通信の片方はNATは以下、片方はグローバルにいる
グローバル側から接続依頼サーバーに通信依頼
NAT配下のクライアントは接続依頼サーバーを定期的にポーリング
接続依頼があればNAT配下側からグローバル側のクライアントに通信開始
TCP前提なのでUDP通信には使えないのがネック
TURN
Traversal Using Relay around NAT
シンプルにグローバル上に通信を中継するサーバーを立てる
データリレー
通信する双方がNAT配下でも問題なし
TCP,UDP両対応可能
中継サーバーの運用コスト、サーバー負荷での通信劣化、非効率な通信と問題点はある。
]
#IPSec_NAT_traversal
#NAT64/DNS64